Fast path message transfer agent

ABSTRACT

A method of providing a fast path message transfer agent is provided. The method includes receiving bytes of a message over a network connection and determining whether the number of bytes exceeds a predetermined threshold. If the number of bytes is less than a predetermined threshold, then the message is written only to memory. However, if the number of bytes exceeds the predetermined threshold, then some of the bytes (e.g. up to the predetermined threshold) are written to memory, wherein the remainder of the bytes are stored onto the non-volatile storage. If the message was received successfully by each destination, then the message is removed from the memory/non-volatile storage. If not, all failed destinations are identified and the message (with associated failed destinations) is stored on the non-volatile storage for later sending.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to sending email messages between servers,and particularly to a fast path message transfer agent for these emailmessages.

2. Description of the Related Art

FIG. 1 illustrates a simplified email system 100 that can send orreceive messages over the Internet 103. System 100 typically uses SimpleMail Transfer Protocol (SMTP) to send messages between servers 101 and102. Clients 104-106 can use server 101 to route their email, whereasclients 107-109 can use server 102 to route their email.

Servers 101 and 102 temporarily store and re-route the email messagesfrom clients 104-109 to the appropriate destinations. Specifically,Message Transfer Agents (MTAS) 110 and 111, installed in servers 101 and102, respectively, can route messages according to addresses designatedin the email. MTAs can use retry logic and queues (explained in furtherdetail below) to efficiently direct the messages.

FIGS. 2A and 2B illustrate a flow chart of a standard embodiment of anMTA operation. In step 201, the MTA, in a first email server, receives anetwork connection from a second email server. The MTA can then receivebytes of a message over this connection in step 202. In step 203, theMTA writes those bytes into a dynamic (e.g. DRAM or SRAM) memory toquickly capture those bytes and then stores those bytes into anon-volatile storage device until delivery to their final destination(s)(i.e. the clients associated with the first email server).

If all bytes of the message have not been received, as determined instep 204, then the process returns to step 202 to receive additionalbytes of the message over the connection. If all bytes of the messagehave been received, then the MTA responds to the server that the messagehas been successfully received in step 205. Note that if a systemfailure (e.g. a full condition or power outage) occurs during steps201-203, then the MTA can respond to the server with an error message,wherein the server can re-establish network connection at a later pointin time to resend the message. In this case, the MTA can delete anybytes of the message that were written to the memory or stored in thenon-volatile storage device.

Assuming successful receipt, the stored bytes for a message in thenon-volatile storage device are now in a queue of messages to bere-routed to their destinations. When a message is next in queue, theMTA retrieves the message from the non-volatile storage in step 206. TheMTA attempts to send the message to each destination designated by themessage in step 207. If the message was not successfully delivered toall destinations, as determined by step 208, then the MTA can identifythe failed destinations in step 210 and then retry delivering themessage to the failed destinations after some delay in step 211. In oneembodiment, the message and its failed destinations can be returned to aqueue in the non-volatile storage device, wherein the process returns tostep 206. If the message was successfully delivered to all destinations,then the message is removed from the non-volatile storage device in step209 and the delivery process for that message ends.

Continuously storing and accessing messages on the non-volatile storagedevice undesirably increases the time of email delivery. Therefore, aneed arises for a method of decreasing email delivery time.

SUMMARY OF THE INVENTION

A method of providing a fast path message transfer agent (MTA) isprovided. A typical implementation of the fast path MTA can increaseperformance by 3× the speed of a standard MTA. The method includesreceiving bytes of a message over a network connection and determiningwhether the number of bytes exceeds a predetermined threshold. If thenumber of bytes is less than a predetermined threshold, then the messageis written only to memory. However, if the number of bytes exceeds thepredetermined threshold, then the message is written to memory and anon-volatile storage device. In one embodiment, some of the bytes (e.g.up to the predetermined threshold) are written to memory, wherein theremainder of the bytes are stored into the non-volatile storage device.

Writing the message to the memory and the non-volatile storage devicecan further include determining whether all bytes of the message havebeen received. If not, then additional bytes of the message can bereceived over the network connection. The additional bytes can bewritten into the non-volatile storage device.

The method can further including accessing the message, sending themessage to each destination, and determining whether the message wasreceived successfully by each destination. if the message was receivedsuccessfully by each destination, then the message can be removed fromthe memory (or from the memory and the non-volatile storage device, asappropriate) and a successful receipt of the message can be indicated.

If the message was not received successfully by each destination, thenall failed destinations can be identified and the message can be storedin the non-volatile storage device. However, a successful receipt of themessage can still be indicated. The failed destinations can be retriedafter a delay until the message is successfully received. At this point,the message can be removed from the non-volatile storage device.

A computer program product is also provided. The product can include acomputer usable medium having a computer readable program code embodiedtherein for providing a fast path message transfer agent. The computerreadable program code can comprise computer readable program code thatreceives bytes of a message over a network connection and computerreadable program code that determines if the number of bytes exceeds apredetermined threshold. If the number of bytes is less than thethreshold, then the message is written only to memory. However, if thenumber of bytes exceeds the threshold, then the message is written tomemory and a non-volatile storage device. The product can furthercomprise computer readable program code that writes some of the bytes(for example, up to the predetermined threshold) to memory and computerreadable program code that stores a remainder of the bytes in thenon-volatile storage device.

Another embodiment of a method for providing a MTA is provided. Thismethod can include receiving a network connection from an email server,receiving addresses of any recipients, and determining whetherconnections can be formed to the recipients. If so, then bytes of amessage can be received and sent to the recipients. If not, then theconnections can be retried for a predetermined number of times.

If the bytes are received by the recipients, then the MTA can respond tothe server that the message was successfully received by the recipients.On the other hand, if not all the bytes are received by the recipients,then the MTA can respond to the server that message transfer was notsuccessful. In the case that retrying exceeds the predetermined numberof times, then the MTA can respond to the server that connections to therecipients were not successful.

Yet another embodiment of a method of providing a fast path MTA isprovided. This method can include receiving a network connection from anemail server, receiving bytes of a message over the network connection,and determining whether the number of bytes exceeds a predeterminedthreshold. In this embodiment, if the number of bytes does not exceed apredetermined threshold not, then the message is written only to amemory. However, if the number of bytes exceeds a predeterminedthreshold, then the message is written only to non-volatile storage.

If all bytes of the message have not been received, then additionalbytes of the message can be received. However, if the total number ofbytes exceeds the predetermined threshold, then the total number ofbytes are stored in the non-volatile storage device and any bytes of themessage written to memory are erased.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a simplified block diagram of an email system thatcan send or receive messages over the Internet.

FIGS. 2A and 2B illustrate a flow chart of one embodiment of a standardMessage Transfer Agent (MTA) operation.

FIGS. 3A and 3B illustrate a flow chart of one embodiment of a fast pathMTA operation.

FIG. 4 illustrates an embodiment in which the fast path MTA operationcan be disabled and the standard MTA operation can be enabled.

FIG. 5 illustrates another embodiment of a fast path MTA that eliminatesthe need for disk storage.

FIG. 6 illustrates another embodiment of a MTA that uses one of a fastpath or a standard path.

DETAILED DESCRIPTION OF THE DRAWINGS

FIGS. 3A and 3B illustrate a flow chart of one embodiment of a fast pathMTA operation. In this operation, storing a message in a non-volatilestorage device is limited to circumstances where the number of bytesexceeds a predetermined threshold. The predetermined threshold is set sothat a majority of the messages can be written only to memory. In thismanner, the delivery time can be significantly reduced compared to thestandard MTA operation (FIGS. 2A and 2B) that must include access timeto the non-volatile storage.

In step 301, the MTA receives a network connection from the emailserver. In step 302, the MTA receives bytes of a message over thatconnection. If the total number of bytes (i.e. bytes written to memoryin combination with those bytes just-received) does not exceed apredetermined threshold, as determined in step 303, then the receivedbytes are written to memory in step 304. If all bytes of the messagehave not been received, as determined in step 305, then the MTA returnsto step 302 to receive additional bytes.

If the total number of bytes exceeds a predetermined threshold in step303, then the number of bytes up to the threshold are written to memoryand the remainder of bytes is stored in a non-volatile storage device instep 306. If all bytes of the message have not been received, asdetermined in step 307, then the MTA receives additional bytes of themessage over the connection in step 308. These additional bytes of themessage are stored only onto the non-volatile storage device in step309. Once all bytes of the message have been received (steps 305/307),the bytes for the message in memory (or in the memory and on thenon-volatile storage device) can be re-routed to their destinations.

Thus, the MTA can follow one of two processes depending on thepredetermined threshold. In one embodiment, the predetermined thresholdis set so that a majority of the messages can be written only to memory.For example, the threshold can be set to 32 k, although other thresholds(such as 16 k or 64 k) can also be used depending on the projected sizeof the files. Because the MTA stores onto and accesses the non-volatilestorage device infrequently (and in preferred cases, not at all), thisprocess is significantly faster than the prior art process. In fact, fortypical implementations, this fast path MTA process can be three timesas fast as the prior art MTA process.

To re-route the message to its destination(s), the MTA accesses themessage from memory (or accesses a portion of the message from memoryand retrieves the remainder of the message from the non-volatile storagedevice) in step 310. The MTA attempts to send the message to eachdestination designated by the message in step 311. If the message wassuccessfully delivered to all destinations, as determined by step 312,then the message can be removed from memory (or memory and thenon-volatile storage device) in step 313. The MTA can respond to theserver that the message was successfully received in step 314 and thedelivery process for that message ends.

If the message was not successfully delivered to all destinations, asdetermined by step 312, then the MTA can identify the faileddestinations in step 315 and then store the complete message (and thefailed destinations) onto a non-volatile storage in step 316. In oneembodiment, the message and its failed destinations can be placed in aqueue in the non-volatile storage device. Note that, in addition tosystem failure or memory problems at the destination, a failed deliverycan occur because of a condition determined at the time of delivery. Forexample, if the message is an 8-bit message and the destination onlysupports 7-bit, then a bit conversion must be done before the messagecan be successfully delivered to that destination. The bit conversion ofthe 8-bit message can be done by a tool activated by the MTA, whereinafter conversion the 7-bit message can be put in the queue of thenon-volatile storage device. Once the message is stored onto thenon-volatile storage device, the MTA can respond to the server that themessage has been successfully received in step 317. The MTA can retrysending the message to the failed destinations after a predetermineddelay in step 318.

If the message is not successfully received by all destinations, asdetermined in step 319, then the MTA can repeat steps 318 and 319. Notethat in one embodiment, after a predetermined of retries, the processproceeds to step 320. Once a message is successfully received by alldestinations, then the message can be removed from the non-volatilestorage device in step 320 and the delivery process for that messageends. Note that receiving another network connection from an emailserver can occur at any time. Thus, one set of steps 301-320 can beinterleaved with one or more other sets of steps 301-320, as needed.

In one embodiment, the fast path MTA can be disabled, thereby activatingthe standard path MTA described in FIGS. 2A and 2B. For example,referring to FIG. 4, after receiving the bytes of the message over theconnection in step 302 (FIG. 3A), step 401 can determine if anypredetermined conditions are present in the message. If no predeterminedconditions are present, then the fast path MTA process can beimplemented (step 402) by proceeding to step 303 (also FIG. 3A). Ifpredetermined conditions are present, then the standard path MTA processcan be implemented (step 403) by proceeding to step 203 (FIG. 2A).

Predetermined conditions can include, by way of example and notlimitation, enabled filtering (e.g. anti-virus, anti-spam, andcontent-filtering), disabled Lightweight Directory Access Protocol(LDAP) relaying (wherein LDAP includes a set of protocols for accessinginformation directories including email addresses etc.), enabledencryption, enabled LDAP “sender masquerading” (feature that refers tothe LDAP directory to replace the sender's name with another entry, suchas the “official” email address for the sender), enabled RealtimeBlackhole List (RBL) (includes a listing of IP addresses whose ownersrefuse to stop spam), enabled “received for header” (feature that causesthe MTA to take a message that is addressed to several destinations andtransform the message into several messages, each message addressed toone of the several destinations), and enabled “sender check” (featurethat ensures the sender's domain exists in the Domain Name System (DNS),an Internet service that translates domain names into IP addresses).Note that although the predetermined conditions indicated above relateto the configuration of the server, other predetermined conditions couldexist to trigger disabling of the fast path MTA.

In accordance with another embodiment of the invention, the need fordisk storage is completely eliminated. For example, referring to FIG. 5,the MTA receives a network connection from the email server in step 501.In step 502, the MTA receives addresses of the recipients. Ifconnections can be formed to all recipients, as determined in step 503,then the MTA receives the bytes of the message in step 504. These bytescan be sent to the recipients in step 505. Note that steps 504 and 505could be performed substantially simultaneously or step 505 could followcompletion of step 504. If the recipients received all the bytes of themessage, as determined in step 506, then the MTA can respond to theserver that the messages was successfully received in step 507. If therecipients did not receive all bits, then the MTA can respond to theserver that the message transfer was not successful in step 508. Notethat if connections cannot be formed to all recipients in step 503, theneither the MTA can respond to the server that connections to allrecipients were not successful in step 509 or, alternatively, the MTAcan retry connecting (i.e. returning to step 503) a predetermined numberof times before responding to the server.

In accordance with another embodiment of the invention, the need fordisk storage is eliminated in the fast path MTA. For example, referringto FIG. 6, the MTA receives a network connection from the email serverin step 601. In step 602, the MTA receives bytes of a message over thatconnection. If the total number of bytes (i.e. bytes written to memoryin combination with those bytes just-received) does not exceed apredetermined threshold, as determined in step 603, then the receivedbytes are written to memory in step 604. If all bytes of the messagehave not been received, as determined in step 605, then the MTA returnsto step 602 to receive additional bytes.

If the total number of bytes exceeds a predetermined threshold in step603, then the fast path MTA is bypassed. Specifically, the bytescomprising the message are stored in a non-volatile storage device andany bytes of the message written to memory are erased in step 607. Ifall bytes of the message have not been received, as determined in step608, then the MTA receives additional bytes of the message over theconnection in step 609. These additional bytes of the message are storedonly onto the non-volatile storage device in step 610. Once all bytes ofthe message have been received, as determined in step 608, the MTA canrespond to the server that the message has been successfully received instep 205 (FIG. 2A). Steps 206-213 (FIG. 2B) can then be followed inaccordance with a standard MTA. Finally, assuming the fast path MTA isstill active and all bytes for the message have been received, asdetermined in step 605, then steps 310-320 (FIG. 3B) can be followed.

In one exemplary computer implemented embodiment, the MTA may be run ona variety of computer platforms including, for example: a SPARC station20 or higher using the Sun™, Solaris™, or SPARC 2.6/2.7 operating systemwith at least 128 MB of RAM. In another embodiment, a PC platform (suchas a Dell PowerEdge™1500) running either RedHat Linux 7.1 or MicrosoftWindows™2000 can be used.

Although illustrative embodiments of the invention have been describedin detail herein with reference to the accompanying figures, it is to beunderstood that the invention is not limited to those preciseembodiments. They are not intended to be exhaustive or to limit theinvention to the precise forms disclosed. As such, many modificationsand variations will be apparent to practitioners skilled in this art.For example, although a non-volatile storage device is discussed herein,any type of stable storage device could be used. In one embodiment, thenon-volatile storage device could be a disk. Note that the predeterminedthreshold could be set to any value, even a value that would eliminatethe need for the non-volatile storage device. Accordingly, it isintended that the scope of the invention be defined by the followingClaims and their equivalents.

1. A method of providing a fast path message transfer agent, the methodcomprising: receiving bytes of a message over a network connection;determining whether the number of bytes exceeds a predeterminedthreshold, wherein if not, then writing the message only to a memory,and wherein if so, then writing the message to the memory and anon-volatile storage.
 2. The method of claim 1, wherein writing themessage to the memory and the non-volatile storage includes: writing aportion of the bytes up to the predetermined threshold to the memory;and storing a remainder of the bytes onto the non-volatile storage. 3.The method of claim 2, wherein writing the message to the memory and thenon-volatile storage further includes: determining whether all bytes ofthe message have been received; wherein if not, then receivingadditional bytes of the message over the network connection; and writingthe additional bytes onto the non-volatile storage; and wherein if so,then proceeding to re-route the message.
 4. The method of claim 3,wherein if the number of bytes is less than the predetermined thresholdand all bytes of the message have been received, then proceeding tore-route the message.
 5. The method of claim 4, further including:accessing the message; sending the message to each destination; anddetermining whether the message was received successfully by eachdestination.
 6. The method of claim 5, wherein if the message wasreceived successfully by each destination, then removing the messagefrom the memory and the non-volatile storage, if on the non-volatilestorage; and indicating a successful receipt of the message.
 7. Themethod of claim 6, wherein if the message was not received successfullyby each destination, then identifying all failed destinations; storingthe message on the non-volatile storage; and indicating a successfulreceipt of the message.
 8. The method of claim 7, further includingretrying the failed destinations after a delay.
 9. The method of claim8, further including: determining whether the message is successfullyreceived by the failed destinations, wherein if not, then returning tothe step of retrying the failed destinations after a delay; and whereinif so, then removing the message from the non-volatile storage.
 10. Themethod of claim 9, further including disabling the fast path messagetransfer agent if a predetermined condition exists.
 11. A computerprogram product comprising: a computer usable medium having a computerreadable program code embodied therein for providing a fast path messagetransfer agent, the computer readable program code comprising: computerreadable program code that receives bytes of a message over a networkconnection; and computer readable program code that determines it thenumber of bytes exceeds a predetermined threshold, wherein if not, thenwriting the message only to a memory, and wherein if so, then writingthe message to the memory and a non-volatile storage.
 12. The computerprogram product of claim 11, further comprising: computer readableprogram code that writes a portion of the bytes up to the predeterminedthreshold to the memory; and computer readable program code that storesa remainder of the bytes onto the non-volatile storage.
 13. The computerprogram product of claim 12, further comprising: computer readableprogram code that determines if all bytes of the message have beenreceived, wherein if not, then receiving additional bytes of the messageover the network connection and writing the additional bytes onto thenon-volatile storage, and wherein if so, then proceeding to re-route themessage.
 14. The computer program product of claim 13, furthercomprising: computer readable program code that proceeds to re-route themessage if the number of bytes is less than the predetermined thresholdand all bytes of the message have been received.
 15. The computerprogram product of claim 14, further comprising: computer readableprogram code that accesses the message; computer readable program codethat sends the message to each destination; and computer readableprogram code that determines if the message was received successfully byeach destination.
 16. The computer program product of claim 15, furthercomprising: computer readable program code that removes the message fromthe memory and the non-volatile storage, if on the non-volatile storage,and indicates a successful receipt if the message was receivedsuccessfully by each destination.
 17. The computer program product ofclaim 16, further comprising: computer readable program code thatidentifies all failed destinations, stores the message on thenon-volatile storage, and indicates a successful receipt of the messageif the message was not received successfully by each destination. 18.The computer program product of claim 17, further comprising: computerreadable program code that retries the failed destinations after adelay.
 19. The computer program product of claim 18, further comprising:computer readable program code that determines whether the message issuccessfully received by the failed destinations, wherein if not, thenreturning to the step of retrying the failed destinations after a delay,and wherein if so, then removing the message from the non-volatilestorage.
 20. The computer program product of claim 19, furthercomprising: computer readable program code that disables the fast pathmessage transfer agent if a predetermined condition exists.
 21. A methodof providing a fast path message transfer agent, the method comprising:receiving a network connection from an email server; receiving addressesof any recipients; and determining whether connections can be formed tothe recipients, wherein if so, then receiving bytes of a message andsending the bytes to the recipients, and wherein if not, then retryingthe connections a predetermined number of times.
 22. The method of claim21, wherein if the bytes are received by the recipients, then respondingto the server that the message was successfully received by therecipients.
 23. The method of claim 21, wherein if not all the bytes arereceived by the recipients, then responding to the server that messagetransfer was not successful.
 24. The method of claim 21, wherein ifretrying exceeds the predetermined number of times, then responding tothe server that connections to the recipients were not successful.
 25. Amethod of providing a fast path MTA, the method comprising: receiving anetwork connection from an email server; receiving bytes of a messageover the network connection; and determining whether the number of bytesexceeds a predetermined threshold, wherein if not, then writing themessage only to a memory, and wherein if so, then writing the messageonly to non-volatile storage.
 26. The method of claim 25, furtherincluding if all bytes of the message have not been received, thenreceiving additional bytes.
 27. The method of claim 26, furtherincluding if the total number of bytes exceeds a predeterminedthreshold, then storing the total number of bytes in a non-volatilestorage device and erasing any bytes of the message written to memory.